ci: tolerate perf comment write failures#1013
Conversation
📝 WalkthroughWalkthroughThis PR adds typed error handling to the GitHub API request helper, introduces resilient comment creation functions that gracefully skip on permission errors, refactors the upsert flow to use fallback creation logic, and appends performance metrics to the GitHub Actions job summary. ChangesGitHub PR comment error handling and resilience
GitHub Actions job summary integration
🎯 2 (Simple) | ⏱️ ~10 minutes
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
.github/scripts/upsert-pr-comment.ts[baseline-browser-mapping] The data in this module is over two months old. To ensure accurate Baseline data, please update: Oops! Something went wrong! :( ESLint: 9.35.0 Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'eslint-plugin-format' imported from /node_modules/.pnpm/@antfu+eslint-config@4.19.0_@vue+compiler-sfc@3.5.30_eslint@9.35.0_typescript@5.9.2_vit_670a2c5c75d4275eabd7bc195a173ee6/node_modules/@antfu/eslint-config/dist/index.js Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Make the perf comment helper fall back to creating a new comment when updating the existing marker comment fails. If GitHub refuses comment writes, as it does for fork pull_request tokens, log a warning and let the performance comparison job finish successfully. Validation: pnpm run format; pnpm typecheck
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
ccusage-guide | 3c23980 | Commit Preview URL Branch Preview URL |
May 17 2026, 02:04 AM |
589fe36 to
3c23980
Compare
@ccusage/amp
ccusage
@ccusage/codex
@ccusage/opencode
@ccusage/pi
commit: |
ccusage performance comparisonThis compares the PR build against the base branch build on the same CI runner. Committed fixture performanceCommitted small fixtures for stable PR-to-PR feedback and explicit Claude/Codex command coverage. Fixtures: Claude
Large real-world-shaped fixture performanceGenerated fixtures shaped from aggregate local log statistics: thousands of JSONL files, many small sessions, and a long tail of larger sessions. No real prompts, paths, or outputs are stored in the fixtures. Fixtures: Claude
Package size
Lower medians and smaller packed package sizes are better. CI runner noise still applies; use same-run ratios as directional PR feedback, not release guarantees. |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/scripts/upsert-pr-comment.ts:
- Around line 91-99: The catch-all in the PATCH block (where githubRequest is
called to update `/issues/comments/${existing.id}`) should not unconditionally
call tryCreateComment on any local error; instead detect whether the update
actually failed server-side before creating a new marker: on error, re-fetch the
comment via githubRequest GET `/issues/comments/${existing.id}` (or inspect the
PATCH response status if available) and only call tryCreateComment when the GET
returns 404/410 or the PATCH returned a clear non-success HTTP status; if the
re-fetch shows the comment exists or the body matches the desired content, treat
the update as successful and do not create a new comment—apply this logic around
the existing githubRequest PATCH and tryCreateComment calls to avoid duplicate
marker comments.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 37691a89-54c0-4e8b-bcd9-e3443b245c0c
📒 Files selected for processing (2)
.github/scripts/upsert-pr-comment.ts.github/workflows/ccusage-perf.yaml
| try { | ||
| await githubRequest(`/repos/${repository}/issues/comments/${existing.id}`, { | ||
| method: 'PATCH', | ||
| body: JSON.stringify({ body }), | ||
| }); | ||
| } catch (error) { | ||
| console.warn(`Failed to update existing PR comment; creating a new comment instead.`); | ||
| console.warn(error); | ||
| await tryCreateComment(); |
There was a problem hiding this comment.
Avoid posting a new marker comment after ambiguous update failures.
This catch-all will create a fresh comment even when the PATCH may already have succeeded server-side and only the response handling failed locally. That can leave duplicate marker comments on the PR, and later runs may keep updating the oldest one while stale copies remain visible.
Safer fallback
} catch (error) {
- console.warn(`Failed to update existing PR comment; creating a new comment instead.`);
- console.warn(error);
- await tryCreateComment();
+ if (error instanceof GitHubRequestError && error.status === 404) {
+ console.warn(
+ 'Existing PR comment no longer exists; creating a new comment instead.',
+ );
+ await tryCreateComment();
+ return;
+ }
+ throw error;
}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/scripts/upsert-pr-comment.ts around lines 91 - 99, The catch-all in
the PATCH block (where githubRequest is called to update
`/issues/comments/${existing.id}`) should not unconditionally call
tryCreateComment on any local error; instead detect whether the update actually
failed server-side before creating a new marker: on error, re-fetch the comment
via githubRequest GET `/issues/comments/${existing.id}` (or inspect the PATCH
response status if available) and only call tryCreateComment when the GET
returns 404/410 or the PATCH returned a clear non-success HTTP status; if the
re-fetch shows the comment exists or the body matches the desired content, treat
the update as successful and do not create a new comment—apply this logic around
the existing githubRequest PATCH and tryCreateComment calls to avoid duplicate
marker comments.
Summary
Why
Fork PRs can complete the perf comparison, but their pull_request GITHUB_TOKEN may not be allowed to write issue comments. The previous workflow failed after successful measurement because comment creation returned 403.
Validation
Summary by CodeRabbit